An Empirical Study of the LSS Specification Toolkit in Use

The LSS (Lightweight Specification System) toolkit assists in the development of logic programs, using a variety of high level specification methods. Many other high level specification systems impose a single, uniform view of how specification should proceed. In practice, there is normally no single understanding of how to describe specifications there are instead a variety of different forms of description which have evolved from the work practices of various domains. Any attempt to disturb these work practices in a radical way will, naturally, meet with resistance unless those who must be educated in new methods can see clearly that they will benefit (soon) from their efforts. LSS addresses this problem by providing a collection of comparatively simple independent tools, each of which is directed at a particular community of users who might reasonably be expected to adjust to the tool without excessive effort. In this sense, LSS is lightweight it is intended to be easy to pick up. Communication between LSS tools is achieved by using Horn Clause logic as a standard language, although users of some of the tools are buffered from the logical details by interfaces targeted at the appropriate group of users. This allows the products of specification from some of the tools to be used as the basis for more detailed specification (perhaps by other people) using other tools. This paper summarises the current LSS system and describes the results of an experiment in applying it to a substantial software engineering task : the specification of one of its own tools. 1 Choice of Empirical Test Ideally, every specification system should be evaluated against at least two fundamental criteria: its general effectiveness in tackling the classes of problems which it will encounter and its specific effectiveness in the hands of those who are intended to use it. Work on LSS began only recently so our experiment addresses the former criterion we are have yet to conduct empirical tests on target groups of users but shall argue that the system is likely to fare well when subjected to this. Even confining ourselves to general effectiveness, there are few published examples of high-level formal specification systems being applied to problems which would be recognised as realistic by practising programmers. The application described in this paper is realistic for the following reasons: • The target program is a medium sized logic program, using approximately 850 lines of code in the definition of 85 predicates. It is not a "toy" application indeed it defines one of the key tools in LSS itself. • The size of predicate definitions varies from 2 lines to 68 lines; the number of arguments per predicate varies from 0 to 8; and a variety of standard definition styles are employed (including various styles of recursive definition as well as the occasional use of "dirtier" styles such as failure driven iteration). The application is not artificially skewed towards a particular type of algorithm or style of development. • Approximately a quarter of the lines of code exist solely to control the windowbased interface to the application. We do not have the luxury of ignoring the dynamics of the interface to the application. • Neither the application nor the LSS toolkit were adapted during the experiment, even when comparatively simple extensions to the knowledge bases of some of the tools could have made the application easier to handle. No "fine tuning" was done to make the system look good. Our empirical test of the current LSS system is straightforward we chose one of LSS's own tools and attempted to regenerate the code for it using LSS. However, the analysis of our results is not so easy, since we are assessing the effectiveness of creative design rather than measuring a carefully controlled process. In Section 4 we shall summarise the results of our analysis, most of which will be qualitative but allowing rough estimates of the productivity of the system. To understand the task performed in the experiment it is necessary to have a flavour of LSS in general and the tool which was reconstructed (the techniques editor) in particular. This is provided in Section 2. An illustrative example of a specification sequence using several tools on a part of the reconstruction appears in Section 3. Readers interested in a broader discussion of the motivation for LSS are referred to [1]. 2 Overview of LSS LSS currently consists of eight tools, each of which is directed at a different form of specification. These tools are shown as rectangular boxes in the central segment of Figure 1. To assist users in performing the task specific to a tool, each harnesses knowledge about the task, as summarised on the left of Figure 1. All of the tools possess tool-specific data structures which are used to store and retrieve its specifications. These are summarised on the right of Figure 1. Some of the tools can also read or write information in the format recognised by the other tools. This is useful for refinement and for assembly. Refinement (as we mean it in this paper) takes place when the partial specification produced by one tool is picked up and extended by another tool (for example, a techniques history produced by the recursion tool may later be loaded into the techniques editor and extended). Assembly occurs when a number of different data files are brought together (for instance, the overview tool connects the predicate definitions from other tools to form a larger specification).